The present invention relates to a bus system that supports atomic transactions in a multi-bus computer system.
Modern computer systems are multi-agent systems. One known system, shown in FIG. 1, includes a plurality of agents 10-50 that communicate with one another over a first communication bus 60. As agents evolved, different bus protocols developed to support them. Thus, additional sets of agents 72-78 and 82-88 communicate over other buses 70 and 80. The bus protocols often are not compatible with each other. Accordingly, although it has become common practice to provide several buses in a single computer system, the system may include at least one bridging agent, such as agent 50, that interfaces to the buses 60, 70 and 80.
In known computer systems, typically there only two different bus types in such systems. One or more central processors 10-40 communicate on a "local" bus 60. Input/output devices may communicate on a "remote" bus 70 or 80.
When an agent 10 must perform an operation to be implemented by an agent 72 of remote bus 70, it issues a bus transaction on the local bus 60. The bridging agent 50 fields the bus transaction, decodes it and issues a bus transaction on the remote bus 70. The agent 72 responds to the transaction on the remote bus 70 and issues a response to be carried back to agent 10. For example, when agent 10 requests data to be read from agent 72, agent 72 issues a response with the requested data. Bridging agent 50 carries the requested data back to agent 10 via the local bus 60. Typically, the bridging agent 50 queues requests and responses carried in either direction across the buses.
As a representative example, consider a computer system where bus 60 is based on the bus protocol of the Pentium.RTM. Pro processor, commercially available from Intel Corporation of Santa Clara, Calif. One or more agents 10-40 may be Pentium.RTM. Pro processors. In this case, the local bus 60 is a pipelined bus. I/O devices 72-78, 82-88 are provided on the remote buses 70, 80. The I/O devices 72-88, 82-88 may communicate using a different bus protocol, such as the known Peripheral Component Interface ("PCI") protocol. An I/O controller 50 supports both the Pentium.RTM. Pro bus protocol and the PCI bus protocol so that transactions issued on the local bus 60 may be implemented on the remote buses 70, 80. For example, a bridging interface 50 may be a model 82450SX OPB integrated circuit, also commercially available from Intel Corp., that supports both the Pentium.RTM. Pro and PCI bus protocols.
The number of different buses in a computer system is expected to rise to increase the number of transactions that may be completed simultaneously by the system. One multiple bus design is shown in FIG. 2. There, a plurality of agents 10-40 are provided on the local bus 60. A local bridging agent 100 interfaces the local bus 60 to one or more intermediate buses 200 and 210. Intermediate bus agents 300 and 310 may perform bridging functions as well; they may interface the intermediate buses 200 and 210 to remote buses 400, 410, 420 and 430. A remote bus such as bus 400 may connect to one or more remote agents 402, 404, 406 and 408. Only one intermediate bus 200 is shown in FIG. 2 between the local bus 60 and a remote bus 400; however, there may be two or more intermediate buses (not shown). By organizing the agents into a plurality of isolated buses, the number of transactions that may be implemented concurrently is increased.
The intermediate bus architecture of FIG. 2 also facilitates scalability. It permits more remote agents to be provided in a single computer system. Accordingly, the computer system is made more powerful.
The multi-bus design of FIG. 2, however, increases the delay of "remote" transaction, a transaction that is issued on a local bus that is directed to an agent of a remote bus. Instead of one bridging agent, a transaction traverses a plurality of bridging agents. Each time a request or a response traverses a bridging agent 100 or 300, the bridging agent fields the request or response from a local bus, decodes it, queues it internally and posts an associated request or response on another bus. Thus, the multi-bus design increases latency of remote transactions.
The performance advantages that are achieved by a multi-bus design may be impaired by a certain set of transactions known as "atomic transactions." Atomic transactions are known in the context of the system of FIG. 1. They occur when one agent issues a number of bus transactions that must be completed in sequence without interruption. Typically, the atomic transaction causes the agent's bus to be locked out against transactions that may be initiated by other agents of the bus. For example, if agent 10 issues an atomic transaction, the bus 60 is locked against other transactions that may be initiated by agents 20, 30 or 40. The bus remains locked until the final transaction in the atomic sequence is completed.
For atomic transactions that are "remote," the local bus 60 is locked during the entire time that it takes the atomic transaction to complete. The bus 60 is locked for the time that it takes the bridging agent 50 to field each request in the atomic sequence, translate it and issue it on bus 70. The bus also is locked for the time that it takes for each response to return from bus 70 to bus 60. As noted, the bridging agent 50 typically queues the requests and responses with other transactions received from the local and remote buses 60, 70. The time that the local bus 60 remains locked increases if the atomic transactions must sit idle in long queues at the bridging agent 50.
Atomic transactions can impair bus utilization and, if not implemented properly, cause system deadlock. In the two bus system of FIG. 1, however, because remote atomic transactions cross only a single bridging agent 50, the queuing delays imposed by the agent are not significant. In multi-bus systems such as the system of FIG. 2, a remote atomic transaction may cross two or more bridging agents. While the intermediate and remote buses 100, 400 process the transaction, the local bus 60 sits idle. However, because it is locked, no other agent can post a transaction. Accordingly, utilization of the local bus 60 suffers. Also, if system components do not permit the local bus to be locked, the system may deadlock. The risk of deadlock increases as the number of buses increases. There is a need in the art for a bus protocol that improves bus utilization during atomic transactions that span multiple buses in a computer system.
In the context of the two-bus system of FIG. 1, it is also known for remote agents to initiate lockout transactions. For example, many remote agents designed for use on remote bus 70 may issue request exclusive access to system memory 90. As a representative example, the PIIX3 and PIIX4 integrated circuits, commercially available from Intel Corp., post such lockout requests using the known PHOLD signaling on a PCI bus. Other types of lockout requests are known. The lockout transaction grants to the remote agent uninterrupted access to the memory 90.
In the multi-bus system, the number of remote buses may increase manifold. The system may be provided with so many remote agents that it becomes impractical to grant the remote agent a lockout. However, to provide backward compatibility to such remote agent the remote buses 400-430 should simulate the lockout. The simulated lockout should: 1) permit a remote agent to lock the remote bus 400, and 2) prevent other agents from posting transactions to the remote agent. Accordingly, there is a need in the art for a lockout protocol for remote initiated lockouts that simulate a remote agent's uninterrupted access to an agent on the local bus.